Robots are machines having both electrical and mechanical systems that allow the robot to be controllably managed to perform intended actions. For example, a robotic arm is a type of robot implemented as a mechanical arm, where the robotic arm may be controllably manipulated into a range of different positions and motions. The robotic arm may further include an end effector or gripping mechanism (such as a robotic hand) which can be used to pick up, hold, and release objects to be manipulated.
Robots may be used in any environment in which it is advantageous to have a mechanical entity automatically handle a task, especially a task that requires precise, repeatable manipulations of objects in the environment. In fact, modern manufacturing facilities often use a variety of robot devices at different stages of the manufacturing process to make, assemble, test, and/or package items being manufactured in the facility.
Robots typically include some sort of control system to control the operation of the robot. Computer code is often employed to guide the operation of the robot, where the computer code is embedded or otherwise loaded onto the robot, and execution of the computer code causes the robot to perform its intended operations.
FIG. 1A shows an example robotic arm 104 whose operation is controlled by a robot controller 102a. A control computer 124 may be used to interface with the robot controller 102a, where the control computer has a user interface to allow a user to send control instructions to the robot (such as “start” and “stop” instructions). The control computer 124 may also include software pertaining to the analysis/processing of data from the robot system.
Consider if the robot arm is employed by an organization as a test platform to perform a manufacturing function, but once the proof-of-concept for the manufacturing task has been approved, the organization would like to move to another type of robotic mechanism (such as a conveyor belt) to perform the manufacturing task. The robotic arm is often used to create and refine a given manufacturing task, given the wide range of control that can be achieved over the motions and articulations of the arm. However, robotic arms are comparatively more complicated and expensive compared to simpler and more specialized devices such as conveyor belts.
Therefore, once the concept behind the manufacturing task has been sufficiently developed using the robotic arm 104 of FIG. 1A, the organization may seek to implement that same task on the factory floor using the simpler device, such as conveyor belt 106 of FIG. 1B.
The issue is that each robot manufacturer typically provides its own unique programming environment to allow its customers to create and install a software application to control the operation of the robot. The robot manufacturer may include a toolkit of functionality that may be called from the software application. In some cases, the software may be implemented using a general purpose programming language (such as Java or C), and on other cases, a specialty software language may need to be employed to create the software application.
However, when implementing a new robot from a different/second robot manufacturer, that second robot manufacturer will likely provide its own programming environment that is different from the programming environment provided by the first manufacturer. This means that users that seek to use a different robot to perform a function may need to engage in a new grounds-up process to create the software for the different/new/second robot, even if the function to be performed by the second robot is similar or identical to the first robot.
In the situations of FIGS. 1A and 1B, this means that even after a first custom application 104a was fully created for the system of FIG. 1A to control the robotic arm 104, a second entirely new and custom application 104b may need to be created for the system of FIG. 1B to control the conveyor belt 106—even if there is a substantial overlap of functionality between custom applications 104a and 104b. 
This situation raises numerous issues for the typical organization. First, since each robot's programming environment is likely to be complex and different from any other type of robot's programming environment, the typical user that seeks to develop software for a robot normally requires a significant investment in training and experience to allow for a competent background to safely and effectively develop the robot's software. Indeed, the robot can be a very dangerous piece of hardware that is capable of destroying itself and things around it at high speed. Thus, it is not advisable to allow a user to develop a custom application for the robot unless that user has been fully trained to do so. However, this severely limits the scope and/or number of users within an organization that are eligible to develop programming for the robots, especially if a number of different robots systems are used within the organization.
Another issue that may exist is that the custom computer code may include information that is considered sensitive and/or proprietary by the organization. For example, the robot may be employed to engage in a manufacturing process where the manufacturing/operating processing and/or conditions are embedded into the operating software, and that information about manufacturing process or operating conditions are considered trade secrets. However, if the robot is being operated and/or provide by a third party (such as a third party contract manufacturer), then a security risk may exist with respect to the organization's trade secretes since the third party would potentially have access to the robot and its custom computer code.
Therefore, for at least the above reasons, there is a need for an improved approach to implement software for robotics systems.